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SUMMARY 

The NASA Lewis Research Center has been given the task of integrating 
the Centaur liquid-fueled upper-stage space vehicle into the Space Shuttle 
program in time to support the Galileo and International Solar Polar 
Interplanetary missions in 1986. To support this integration, a system to 
simulate and emulate the STS-Centaur avionic flight system and its support- 
ing ground control and checkout equipment has been selected. The system has 
been designated the “systems integration facility" (SIF) and is located at 
General Dynamics Convair in San Diego, California. The SIF is composed of 
integrated simulators that form a composite control system complement to the 
STS-Centaur airborne and avionic support equipment. 

The SIF provides an off-line capability to verify the system design of 
the Centaur airborne support equipment (CASE) and the Centaur avionic flight 
system. In addition, it provides a realistic medium for the development and 
integration of ground checkout and airborne control software programs. 

Each simulator is composed of prototype hardware, where feasible, to 
maximize configuration likeness. Where emulated flight or ground hardware 
is used, it provides physical characteristics (loads, signals, etc.) equiva- 
lent to those of the flight hardware. This report describes the hardware 
and software implementation of the SIF. 


INTRODUCTION 

Simulation may be defined as the representation of a device or phenome- 
non by another device or phenomenon in order to achieve some advantage over 
using the prime object for the purpose intended. The advantage may be 
economy, timeliness, or ease of observation or measurement. 

Simulation and emulation is used for STS-Centaur, broadly speaking, 

(1) To study the performance of the STS-Centaur system of devices by 
allowing wide manipulation of the device characteristics (i.e., an 
off-line capability to verify the design of the Centaur integrated 
support system (CISS) and the Centaur avionic flight system) 

(2) To quickly solve theoretical functional problems that may require 
intensive calculations when solved by analytic means 

(3) To provide functional ground support and STS-Centaur hardware sys- 
tems for the development of the computer-controlled launch set 
(CCLS), the digital control unit (DCU), and the control unit (CU) 
ground checkout and flight software programs 

(4) To analyze the effects of multiple component failures of mission- 
critical control functions 







To illustrate the use of this method in one of the most modern fields of 
technical development, this report describes the application of simulation 
in developing STS-Centaur automatic checkout systems. 

This report elaborates on both the design of the simulator system and 
some of the more important simulation methods used in the systems integra- 
tion facility. The discussions center on 

(1) The development of the SIF 

(2) Software simulators and checkout equipment (the CCLS) and their 
present and future roles in connection with STS-Centaur 

(3) The simulators and the SIF laboratory and their roles in the 
development of the STS-Centaur systems 

(4) The types of simulators used in previous Centaur checkout systems 
{prototype equipment module (PEM) and Atlas electrical missile 
simulator (AEMS)) and their shortcomings for current STS-Centaur 
systems 


GENERAL 

The requirement of the STS-Centaur project to provide realism in the 
functional exercising of the STS-Centaur space vehicle necessitated the 
development of the SIF at General Dynamics Convair in San Diego, 

California. Furthermore, regardless of the type of implementation (analog 
or digital), the SIF must behave like the planned STS-Centaur system. It 
also had to be developed early in the design, and before the fabrication, of 
the STS-Centaur. In parallel with this operation, the ground support equip- 
ment was designed, installed, and checked. 


ARCHITECTURE 

Figure 1 depicts the overall configuration of the SIF and its support- 
ing ground equipment. The SIF is a programmable checkout system capable of 
emulating the Centaur airborne systems, the combined STS-Centaur systems, 
and the integrated vehicle checkout, testing, tanking, and launch of the 
STS-Centaur. The SIF is so designed that after it is used for integrated 
laboratory testing of the STS-Centaur at General Dynamics Convair in 
California, the SIF can be transported to Kennedy Space Center, Florida, to 
verify the operational readiness of the STS-Centaur prelaunch and launch 
complexes. 


Computer-Controlled Launch Set 

Control and data-processing functions for the SIF are provided by the 
CCLS system (fig. 1). The CCLS includes a general-purpose Harris-800 high- 
speed digital computer with standard peripheral devices and specialized in- 
put and output devices for communication with the STS-Centaur or the SIF and 
other elements. The Harris-800 computer has three main sections: 

(1) The memory section provides fast-access storage for data and 
instructions. 

(2) The arithmetic and control section performs arithmetic logic and 
shifting operations. The control portion contains the necessary logic for 
controlling and sequencing the events that occur in the computer. 
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(3) The input and output section contains the logic for instructing 
external devices; scanning for external interrupts; and communicating with 
the operator's console, the telemetry station, the mobile support equipment 
(MSE), and the airborne digital computer. All data enter and leave the CCLS 
via the local digital interface equipment (LDIE) and the remote digital 
interface equipment (RDIE), which interface the CCLS with the outside 
world. The RDIE is used on Complex 36 for launching Atlas-Centaur 
vehicles. It plays no role in the STS-Centaur systems. The LDIE is used 
for both Atlas-Centaur and STS-Centaur. Both DIE's are current-technology 
equipment, and no major changes are scheduled for them. 

The MSE is a mobile interface between the CCLS and the STS-Centaur 
vehicle and its associated ground support equipment. Housed within the MSE 
are the hardware extension remote (HER), the terminal distribution system, 
and the communication electronics. The HER provides the remote interface to 
the CCLS and thus allows the CCLS to communicate to and monitor Centaur and 
CISS flight hardware and associated launch ground support equipment (GSE). 
The HER is composed of two remote interface controllers (RIC), prime and 
backup; two Harris-100 computers; and an analogic data acquisition system. 
The RIC controls and monitors the launch and checks out the hardware inter- 
faces. The terminal distribution system provides the electrical and com- 
munication links between the Centaur, the CISS, and the tanking skids. The 
major interfaces of the CCLS are depicted in figure 2. 

CCLS Software 

The CCLS software consists of a resident (executive) program, tenant 
programs, and non-time-sharing programs (fig. 1). The tenant programs are 
of two categories: CCLS system programs and airborne system programs. The 

CCLS system programs support the operation and maintenance of the CCLS hard- 
ware and software independently of any external ground support equipment or 
airborne system. The airborne system programs initiate and verify the 
flight readiness of the airborne systems hardware and software. Airborne 
system programs also control external ground support equipment in support of 
launch countdown procedures. The CCLS can execute eight tenant programs 
simultaneously at the operator console stations. 

The CCLS that currently supports Atlas-Centaur missions is being phased 
out. It consists of a Harris/4 computer system with standard peripherals 
and specialized input/output units. Supporting both Atlas-Centaur and 
STS-Centaur missions requires the handling of approximately 40 percent more 
CCLS software tasks. This requirement preempted the use of the current CCLS 
(Harris/4 - memory restraint) and necessitated its replacement. To conserve 
time and cost, the Centaur project decided to use the Harris-800 computer 
because of the ease of moving and translating current software from one 
Harris system to another. 


SIF OVERVIEW 

In designing the SIF the combined airborne systems and the operations 
were first analyzed to identify all of the individual functions necessary to 
verify STS-Centaur launch readiness. Not only was each item of ground sup- 
port equipment necessary for the checkout and launch of the STS-Centaur avi- 
onic flight systems identified, but each item was also associated with the 
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applicable countdown activity and the functional testing of airborne sys- 
tems. Then each item was reviewed in detail to determine its purpose (use 
of prototype flight hardware or emulation), its required input and output, 
its general operating modes, its components, and its relation to other 
items. This was accomplished by analyzing functional requirement documents 
(FRD's), which provided functional descriptions of the equipment. From 
these sources and engineering analysis, functional and specification re- 
quirements were prepared for the SIF and its associated ground support 
equipment to clarify the relations between the elements of the airborne sys- 
tems and the launch support equipment and among the components of each 
element. 


SIF - GENERAL DESCRIPTION 

The STS-Centaur presents an entirely different picture of the role of 
simulation. With the advent of automatic checkout systems and the use of 
digital computers, telemetry data can be used as an integral part of the 
checkout. This is particularly true of the STS-Centaur, where multiple 
interfaces (spacecraft, Centaur, Orbiter, etc.) are involved. The use of 
pulse code modulation (PCM) data interleavers has radically reduced the num- 
ber of signals (particularly analog signals) that must be hard-wired out of 
the stages. Thus the checkout of the digital acquisition system has become 
an integral part of the overall checkout and is a prerequisite for the oper- 
ation of the CCLS-SIF system. Any simulator that is to verify the func- 
tional integrity of the flight systems and their checkout procedures and 
programs must supply a telemetry (digital data acquisition system) link to 
the checkout system. Furthermore parameter values transmitted over this 
link must be responsive to hard-line commands from the checkout system. 

The most difficult tests to develop for the STS-Centaur stages are the 
propulsion subsystem tests and the overall simulated tanking functions - not 
only in the factory checkout, but also in verifying launch complex readi- 
ness. In these tests and simulations there is a direct interaction between 
the facility supplies and the vehicles. The control and regulation of the 
facility supplies require considerable development. The operation of the 
facility supplies presents a higher degree of danger to equipment and per- 
sonnel than pure electrical tests. The danger is magnified when cryogenic 
loading is required. Therefore, for STS-Centaur, development effort 
(simulation/emulation) and analysis has been concentrated on controlling 
these systems and providing the appropriate safety functions (CASE). This 
area is one of the main deficiencies in the current Atlas-Centaur (PEM-AEMS) 
simulators; that is, they are deficient in simulating the interaction of the 
launch complex facilities and the vehicles for checkout at the factory, ex- 
cept for manual inputs at the test set to simulate certain vehicle re- 
sponses. Because of the large number of unknowns the Centaur project has 
required the facility and the vehicles to be simulated in such a way that 
prelaunch, launch, and flight checkout programs are developed before the 
actual operations. 


SIMULATORS 

The major interfaces of the SIF are illustrated in figure 3. The major 
hardware elements are the prototype Centaur vehicle, the Shuttle-peculiar 
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stage portions, and the ground support equipment. Because the STS-Centaur 
simulators are rack-mounted prototype avionic hardware modules and electri- 
cal simulation assemblies, they are easily transportable. 

Flight article connectors and harness assemblies are used for interfac- 
ing the modules. A simulated hardware module is designed to provide equiva- 
lent physical characteristics of a specific item of flight or ground support 
hardware. For example, simulation of fluid, mechanical, and electromechani- 
cal systems is designed to provide equivalent source and loading character- 
istics of the monitor and control signals (i.e., true signal delay times). 

In automatic checkout systems involving simulated and emulated hardware the 
timing of responses to commands takes on additional significance. For 
example, if relays are employed to simulate vehicle valves, the response 
characteristics are considerably different from the actual valve operation. 
In a computer-controlled system such a difference is not allowable if valid 
(realistic) procedures and programs are to be developed. Experience has 
shown that a major area of test programming requiring modification is timing 
between commands and their responses or between commands and other com- 
mands. In the SIF each simulator contains the necessary timing and control 
logic to monitor the status of all inputs. The control circuitry uses these 
input statuses to generate functionally equivalent digital and analog-timed 
response signals. 

Sandwich boxes are provided at the avionic module interface connectors 
for fault insertion. Fault insertion for fluid system simulation (i.e., 
tanking and tanking skid operations) is done by the microprocessor con- 
troller software, which provides erratic transducer responses to simulate 
the results of failed valves or transducers. 

Simulation is used to analyze the effects of multiple component fail- 
ures and worst-case time-phase asynchrony for mission-critical control func- 
tions. Simulation provides a tool whereby the integrity of the control 
safety design is demonstrated. This aspect of simulation is required to 
meet the dual-failure-tolerant redundancy imposed by the Space Shuttle pro- 
gram (i.e., verification of the control concept for both flight hardware and 
imbedded software). Dual-failure tolerance refers to avionic controls that, 
after two control units are lost, leave at least one subsystem branch still 
in control. (The control units are five autonomous Z-80 microprocessors 
located in the CISS.) All safety-related vehicle functions are under the 
control of the Centaur airborne support equipment (CASE)-*- during prelaunch, 
ascent, on-orbit, and abort operations until separation. The simulation of 
CASE includes a detailed operation of its safety-related control subsystem. 

The Centaur liquid-oxygen and liquid-hydrogen tanks are also simulated 
systems. The tanking simulators are the electrical equivalent of the 
Centaur tanking functions and associated monitor element responses. They 
are controlled by accepting tank fill, pressurization, vent, drain, and dump 
commands from the CCLS, the Orbiter, or the Centaur and CISS simulators. 

The tanking skid simulator, an electrical equivalent of the helium, liquid- 
oxygen, and liquid-hydrogen tanking skids, provides equivalent valve load 


1-CASE is composed of the CISS avionic systems (i.e., those electronic and 
electrical items associated with the control of all safety functions 
related to the Centaur vehicle as long as it resides in the Shuttle cargo 
bay). CASE avionics are located on the CISS equipment shelf in the Shuttle 
cargo bay. 
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characteristics and analog equivalents of transducers and sensors. The sim- 
ulator software is used to simulate the active environmental control of the 
Centaur and the tanking skids. The Z-80 microprocessor simulation assembly 
receives conditioned valve status discretes from the Centaur and CISS simu- 
lators and outputs simulated pressure transducer responses based on the 
incoming valve status information under CCLS control. 


SIMULATOR DESCRIPTIONS 

The following discussions highlight some of the system functions and, 
where appropriate, emphasize the driving requirements. 

Centaur Simulator 

The Centaur simulator provides the fluid, mechnical, electromechanical, 
and pneumatic monitor and control functions. Prototype hardware is used and 
consists of the digital computer unit (DCU), the inertial reference unit 
(IRU), the systems electronics unit (SEU), the servo inverter unit (SIU), 
the remote multiplexer unit (RMU), the signal-conditioning unit, telemetry, 
the tracking and command subsystem, the star scanner, the dual-failure- 
tolerant arming sequencer (DUFTAS), the engine actuators, and the 
servopositioners. 

Simulation electronic assemblies are provided for the star scanner, the 
battery system, the solenoid and pyrotechnic valves, the hydraulic system, 
and the propellant tank and level-indicating systems. Figure 4 is a block 
diagram of the Centaur simulator interfaces. The star scanner simulator 
(fig. 5) provides the Centaur simulator with digital star coincidence sig- 
nals and analog star magnitude and video threshold outputs. The Centaur 
simulator in turn transmits digital video threshold commands and self-test 
commands to the star scanner simulator. These signals are used to update 
the guidance system on the Centaur simulator. 

The tanking simulator (fig. 6) receives from the Centaur simulator 
valve assembly conditioned valve discretes that represent the active and 
inactive states of the valves. The Centaur simulator, in turn, receives 
simulated transducer outputs from the tanking simulator. The fluid systems 
(CISS and Centaur) are simulated by a Z-80 microprocessor assembly that re- 
ceives the conditioned valve status discretes from the Centaur and CISS 
simulators. The Z-80 outputs simulated pressure transducer responses based 
on the incoming valve status information. The microprocessor reads the in- 
put status words and performs the necessary software tasks (table lookup, 
matrix manipulation, etc.) to define the associated pressure transducer 
responses. These digital words (representing the transducer's response to 
the input conditions) are then sent to the appropriate digital-to-analog 
converter which outputs a dc analog signal to its particular monitor and 
control element (e.g., Centaur DCU or CISS control units). The tanking 
simulator is controlled by accepting tank fill, pressurization, vent, drain, 
and dump commands from the CCLS, the Orbiter, the launch processing station 
(LPS), the Centaur sequence control unit (SCU), or the CISS control distri- 
bution unit (CDU). One-hundred and twenty simulated valve loads can be 
driven from the CISS and Centaur valve simulation assemblies, and 48 indi- 
vidual simuated transducer outputs can be monitored by the CISS CU's, the 
RMU's, the Centaur DCU, and the Orbiter multiplexer-demultiplexer (MDM). 
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Auxiliary tanking simulation programs (tanking scenarios) and real-time con- 
trol commands can be received from the CCLS HER by the uplink (serial data 
uplink and downlink (PCM)) interface from the mobile support equipment. 

The pyrotechnics on the Centaur are also simulated, and their actuation 
states are displayed. The command discretes to the tanking simulator's emu- 
lated solenoids and pyrotechnics provide a closed-loop simulation. Excita- 
tion state feedback is also provided to the tanking simulator micro- 
processor's interface input and output unit. Figure 7 is a typical diagram 
of an emulated solenoid valve used for simulation. 

The tanking skid simulator (fig. 8) is a single bay of rack-mounted 
prototype and simulation chassis assemblies. This simulator is controlled 
by the commands from the mobile support equipment. It electrically simu- 
lates the tanking skid's pneumatic and solenoid valves, pressure and temper- 
ature transducers, current-to-pressure converters, and valve-positioning 
signals. It contains three prototype skid control panels for liquid oxygen, 
liquid hydrogen, and helium that interface to the skid simulator. The skid 
simulator receives analog and conditioned discrete valve command signals 
from the three skid control panels. The skid simulator then synthesizes the 
feedback responses of the transducers, the sensors, and the valve status 
signals. These output responses are retransmitted back to the CCLS hardware 
extension remote through the skid control panels. Through the uplink- 
downlink interface the skid simulator can receive auxiliary simulation 
scenarios or real-time control capability from the CCLS hardware extension 
remote. 

The simulations of the propellant level indication system (PLIS) probes 
and the overfill sensors for the liquid-oxygen and liquid-hydrogen tanks are 
independent of the probes during the tanking simulation scenarios. A sand- 
wich box at the interface between the propellant level indication unit 
(PLIU) and the RMU and CU in the CISS simulator provides jumper access for 
the simulated analog and discrete quantity status signals originating from 
the tanking simulator - simulating the PLIU outputs respective to tank quan- 
tity status. The analog status signals and overfill discretes are con- 
trolled by the tanking simulator's microprocessor. The capacitive fill 
probes and resistive overfill probes that interface with the PLIU are simu- 
lated systems. A sandwich box at the Centaur simulator's SIU-RMU inter- 
connect provides analog signals for the liquid-oxygen and liquid-hydrogen 
quantity status during simulated tanking. These analog signals simulate the 
propellant utilization system (PU) probes from the tanking simulator and are 
jumpered to provide the analog status to Centaur's RMU. The signals are 
controlled by the tanking simulator microprocessor. 

The deployment simulator (fig. 9) electrically emulates the deployment 
adapter mechanism's monitor and control signals. It is electrically equiva- 
lent to the motor and clutch loads of the deployment adapter flight hard- 
ware. It samples the three phases of ac power, determines the direction of 
rotation, and generates discrete signals representing fully deployed or 
fully stowed and an analog signal for midrotation positioning information. 
Upon activation of the deployment power switching system, all control and 
monitor signals are emulated in real time and transmitted to the respective 
control units in the CISS simulator. The entire deployment procedure is a 
sequenced event begun by redundant command discretes to the CISS simulator 
control units from a switch panel in the Orbiter interface emulator panel. 
Full deployment is achieved in 600 seconds. Rotation direction is deter- 
mined by attenuating and shaping the input ac phases into transistor- 
transistor logic (TTL) level pulses. The three-phase pulses are inputs to a 
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control circuitry that determines rotation direction and outputs these 
numbered redundant position discretes to the control units in the CISS simu- 
lator. The position discretes verify the control interface between the 
deployment control and the control units. When the control units receive 
the full deploy position discretes, they begin to cut off the rotation 
mechanism (simulated) motor. 

The Orbiter simulator (fig. 10) simulates the avionic interface from 
the Centaur cargo element to the Orbiter. Flight service functions provided 
by the Orbiter are simulated as follows: 

(1) Telemetry and data services to monitor the status of the Centaur 
cargo element in the attached and detached modes 

(2) Command interface for controlling on-orbit deployment functions 

(3) Displays and controls for crew status monitoring and safety 
functions 

(4) Power and cable interfaces 

The Orbiter simulator (interface emulator) also provides the necessary com- 
mand and control signals as well as measuring and monitoring capability to 
perform parametric testing of selected interface signals with auxiliary 
laboratory equipment. 

The remainder of this section focuses on the role of the control units 
in the CISS simulator in order to highlight the Centaur airborne support 
equipment (CASE), which controls all Centaur and CASE safety-critical sys- 
tems. The CISS simulator (fig. 11) is a rack-mounted prototype and pre- 
flight simulation of the actual flight article. The functional prototype 
modules that make up the CISS are the signal-conditioning unit, the digital 
control unit (DCU), the control units (CU), the remote multiplexer units 
(RMU), the electrical distribution unit (EDU), the propellant level indicat- 
ing unit (PLIU), the pryo initiator controller (PIC), and the control dis- 
tribution units (CDU). Simulation assemblies are provided for the Centaur 
development system and for the fluid and electrical systems. 

Data uplink and PCM downlink lines between the CCLS mobile support 
equipment and the Centaur DCU, the CISS, the control units, and the CISS DCU 
pass through the CISS simulator's EDU for isolation and lightning protec- 
tion. The CISS has a separate PCM downlink to the PCM interface rack in the 
mobile support equipment. The control units shift the CISS data into the 
DCU, which encodes them into a PCM signal for transmission over the PCM 
link. The hardware extension remote (HER), resident in the mobile support 
equipment, transmits (uplink) five redundant sets of serial data to each of 
the five control units and an independent serial uplink to the CISS simu- 
lator's DCU. In addition, the CISS simulator has another PCM data link from 
its DCU to the payload data interleaver in the Orbiter simulator. 

The CISS simulator contains five independently operating control units 
(Z-80 microprocessors) . Their interconnecting harness forms the voting 
plane to control the loads, the pneumatic and fluid control systems, and the 
Centaur tanks. Operation includes all normal and backup control strings and 
covers all modes of preflight and flight. (Fig. 12 is a block diagram of 
the safety control functions.) The CISS simulator actively controls Centaur 
while it is in the Shuttle cargo bay and provides a dual-fault-tolerant con- 
trol of all safety-critical functions. 

Control Unit Methodology 

The CU control system, in general, bases its control response on the 
"end function" result. The end function is a significant subsystem measure- 
ment that is supplied to the five independent control units as a basis for 
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determining further control action. To begin a control action requires that 
the five control units vote, thus affecting the end function result. For 
example, the venting and pressurization subsystems of the Centaur propellant 
tanks are based on tank pressures and not on downstream individual component 
measurements. This reduces feedback while maintaining high reliability. 

Each control unit executes and outputs a majority rate that forms a plane of 
control for the load. This enables compliance with the requirement to main- 
tain control after sustaining two component failures. Relay networks are 
used to produce a three-out-of-five vote to supply power to activate the 
loads. To complement the electronics, the fluid systems are structured by 
using series and parallel combinations to complete the double-fault-tolerant 
systems (DUFTAS). 

To implement the DUFTAS concept, two basic relay networks are used to 
command the intended function when a component or system fails. These net- 
works positively control the load to be on when commanded "on" and "off" 
when commanded off. One type of network allows one failure to occur (single- 
fault tolerant). The second type of network allows two failures to occur 
(dual-fault tolerant). These networks are wired between control units and 
are terminated in the CDU for load isolation. 

Command decision measurements are spread across all CU's to maintain 
the fault tolerance of the system. Certain critical measurements (e.g., 
analog pressure transducer readings) are cross-strapped among the control 
units. There are several discrete control signals into the control units: 
Orbiter can command abort functions or self-test functions, and ground con- 
trol (i.e., CCLS) can command abort or checkout functions. 

The functional operations of all control units are identical. Each 
operates on a timed update cycle. At the beginning of each cycle the con- 
trol units read their respective sensor input measurements and discrete 
command inputs. Each determines its independent course of action by calcu- 
lating end function trigger points or function sequences with respect to the 
current mode of flight (or simulated flight). The desired state of each 
function is correlated to the state of the necessary switching relays. The 
relays are updated in banks, with the priority function relays in the first 
banks. The control unit then performs housekeeping tasks until the top of 
the next cycle. 


CISS Centaur Airborne Support Equipment 

During ground checkout tests CISS CASE is responsible for safe control 
of Centaur. All test functions are begun and controlled by the CCLS. The 
test objective of the systems integration facility, in a sense, is to exer- 
cise the primary and secondary subsystem functions necessary for developing 
control unit software operational modes and the CCLS test programs. The 
simulations in normal operation will exercise all of their checkout func- 
tions. The simulated tests include the CCLS interface and those ground 
checkout functions necessary for the performance of all of the interrelated 
systems and subsystems. 

Current Atlas-Centaur Simulators 

The PEM-AEMS simulators that are used to verify the CCLS operating pro- 
grams for current Atlas-Centaur launches are in many ways similar to the 
SIF. These simulators are designed such that the flight avionic systems 
would respond to inputs in much the same manner as the Atlas-Centaur under 
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test (i.e., the PEM and AEMS both use prototype flight avionic hardware). 
Manual operations, however, are provided for where the output is a direct 
result of a nonelectrical input (e.g., pneumatic, hydraulic, or tanking sys- 
tems). These simulators are designed chiefly to verify and check out the 
combined Atlas and Centaur avionic systems using CCLS operational programs. 
In certain cases, time-delay circuits are used within the PEM-AEMS configur- 
ation to allow checkout of interlocking or sequencing circuitry between the 
combined vehicles and the spacecraft interface. 

With the advent of STS-Centaur, this type of simulation became invalid 
because of the following shortcomings: 

(1) Lack of simulation of facility-vehicle interaction 

(2) Lack of timing response characteristics 

(3) Lack of exercising safety-related functions 

(4) Lack of simulating fault conditions or scenarios 

(5) Lack of providing Centaur liquid-oxygen and liquid-hydrogen tank- 
ing characteristics 


CONCLUSIONS 

A more realistic simulator-emulator system was needed for STS-Centaur 
than was available at the outset of the STS-Centaur program. This need was 
satisfied by the development of the computer-controlled launch set (CCLS) 
and the system integration facility ( S IF ) described in this report. The 
CCLS-SIF costs less than the simulators presently used to support the 
Atlas-Centaur missions. It can realistically simulate the type of opera- 
tions (preflight and flight) required of the STS-Centaur and enhances the 
readiness of combined vehicle operation before actual flight. 

Past experience with the prototype equipment module - Atlas electrical 
missile simulator - computer-controlled launch set (PEM-AEMS-CCLS) simula- 
tion approach and its shortcomings led to consideration of a more sophisti- 
cated type of simulation. The simulation considered for the SIF provides a 
high degree of verification as a hardware simulator and eliminates the addi- 
tional burden on the design of software simulation and modeling language 
programmers. The emulators were designed from test design information and 
specifications independently of the test requirements or test programs. 

They were designed to run in real time much the same as the actual hardware 
would. This was accomplished by designing the CCLS-SIF computer program 
such that it actually emulates the systems and subsystems within the missile 
stages. In its most complete form the SIF simulates all of the interactions 
between the various subsystems and responds not only to correct inputs but 
also to incorrect inputs in the same way the missile stages would. To pro- 
vide this capability, the representation of the subsystem, or parts thereof, 
must do more than merely provide an overall transfer function for expected 
sequences of input. For example, if the missile's bus voltage is low (by 
design or error), the subsystems should react to this low voltage and pro- 
vide appropriate deviations in its output. 

Advantages 

Past experience has indicated that using simulated and emulated hard- 
ware in developing missile airborne hardware, ground checkout systems, and 
their associated operating procedures is cheaper than a computer modeling- 
simulating system. It is also more timely since the simulation can be 
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developed before manufacturing of the stages is completed. Measurement and 
observation is easier since special capabilities can be built into the simu- 
lation equipment for those purposes. The advantages of simulated and emu- 
lated hardware and of software modeling techniques are compared in the 
following table: 


Simulation or 
emulation method 


No simplifying assumptions are 
necesary if tests are run on an actual 
system. The true behavior of the 
system is revealed. 

Accurate measurements are necessary 
to give a true picture. 

Test and launch procedures and 
associated computer programs are 
debugged at the factory before usage 
at the launch site. 

The time required for design, construc- 
tion, and debugging of hardware is 
reduced. 


Software 
modeling method 


Results usually are of general use rather 
than for restricted application. 

Simplifying assumptions are required. Thus, 
not the actual physical system but a sim- 
plified "mathematical model" of the system 
is studied. Theoretically predicted behavior 
could be different from actual behavior. 

This method is used for experimental studies 
since adequate theories or knowledge may not 
be available. 

This method can lead to complicated software 
problems. 

Long time delays may be engendered in build- 
ing modules and in assembling, checking, 
debugging, and gathering data. 


To date, few simulated and emulated systems are in use and the "prime 
systems" being studied are less complex than space systems. However, as 
these systems become more complex (e.g., to simulate nuclear powerplants, 
NASA's future space station, and new energy technology), they will take on 
many characteristics of the SIF system described in this report. Clearly 
the degree of automation used is directly proportional to the degree of 
similarity required between prime and simulator equipment. As automatic 
systems become more sophisticated, so must the simulation used. 
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APPENDIX - ABBREVIATIONS AND ACRONYMS 

AEMS Atlas electrical missile simulator 

CASE Centaur airborne support equipment 

CCLS computer-controlled launch set 

CDU control distribution unit 

CISS Centaur integrated support system 

CPU central processing unit 

CRT cathode ray tube 

CU control unit 

CWEA caution and warning electronics assembly 

DCU digital control unit 

DMA direct memory access 

DUFTAS dual-failure-tolerant arming sequencer 

EDU electrical distribution unit 

FRD functional requirement document 

GSE gound support equipment 

HER hardware extension remote 

IRU inertial reference unit 

LCC launch control center 

LDIE local digital interface equipment 

LPS launch processing station 

MDM multiplexer-demultiplexer 

MDS microprocessor development station 

MSE mobile support equipment 

OTC out-of-tolerance condition 

PCM pulse code modulation 

PDI payload data interleaver 

PEM prototype equipment module 

PI payload interrogator 

PIC pyro initiator controller 

PLIS propellant loading indicating system 

PLIU propellant level indicating unit 

PSP propellant signal processor 

PU propellant utilization system 

RDIE remote digital interface equipment 

RIC remote interface controller 

RMU remote multiplexer unit 

SCU sequence control unit 

SEU system electronics unit 

SIF systems integration facility 

SIU servo inverter unit 

TTL transistor-transistor logic 

VPF vertical processing facility 

XDCR transducer 
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Total SIF development 


Software development 


Hardware development 


I 


Compute r-controlled 
launch set (CCLS) 





1 


Operational software 


—Control and 

monitor avionics 
—Control and 
monitor CISS 
—Control and monitor 
Centaur tanking system 
—Exercise system for 
fault isolation 

— Generate historical 

data and records 
—Verify flight readiness 
of avionic systems 

— Update digital control unit 

(OCU) routines 
-Output PCM-DCU-CU 
measurements to 
analog recorders 
—Monitor red lines 
forOTC 

— Calibrate guidance 
system, PU, and PUS 


Basic software 


—Compiler 

—Assembler 

— Executive 
—Control and monitor 

input and output 

— Utility programs 
—Manage and service 

communication links 

— Control man-machine 

input and output 



—Simulate tanking 
and tanking skids 

—Develop control unit 
sof twa re 

—Design and test 
control units 

—Simulate fluid 
systems 

—Control and monitor 
CCLS-S IF 

— Simulate or induce 
fault scenarios 


Harris-800 CPU 


Operator control 
console 


Tanking cathode-ray- 
tube console 


CCLS-DMA links 


Interface units 



Emulato rs 


-r 

Decommutators | 


-c 

Recorders [ 


h: 

Strip charts 1 


Radiofrequency 
test set 


Remote digital 
interface equipment 
(RDIE) 


Local digital 
interface equipment 
(LD IE) 


Mobile support 
equipment 1MSE) 


Hardware extension 
remote (HER) 


— Harris-100 CPU 

— Analogic input and 

output units 

— Communication links 


Terminal distribution 


— Uplink to Centaur 

— Uplinks and 

downlinks to CISS 

— Tanking skids 

— Complex 39 launch 

processing station 
(LPS) system 


Figure L - Overall configuration of systems integration facility and ground equipment 
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Figure 2. - Computer-controlled launch set interfaces, 







Figure 3. - Systems integration facility major interfaces. 



Figure 4. - Centaur simulator interfaces, 

















Figure 5. - Star scanner simulator interfaces. 



Figure 6 0 - Tanking simulator interfaces. 
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Figure 7. - Load emulation solenoid valve. 
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Figure 8. - Tanking skid simulator interface. 






Centaur integrated support system simulator 



Figure 9. - Deployment simulator interfaces. 



Figure 10. - Orbiter simulator interfaces. 
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Figure 11. - Centaur integrated support system (CISS) simulator interfaces. 


















Figure IZ - Control unit flight safety control functions. 
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